Žnderungen am FLIC-Player FLICTCxx.PRG 28.10.94 Version 4.0.0 (ehemals 3.6.0 ...) Es klappt! Es klappt! Der Player kann nun auch FLCs abspielen! Mein Dank gebhrt Alexander Clauss, der mir mit Informationen ber das FLC-Format aushelfen konnte; der c't-Artikel war in dieser Hinsicht leider nicht sehr ergiebig. Momentan gibt es noch Probleme mit vereinzelten FLIs (z.B. 7J7.FLI), bei denen der Player das Ende nicht richtig erkennt und einfach abbricht, trotzdem werde ich diese Version ver”ffentlichen, da nur wenige FLIs betroffen sind und der Fehler auch schon in allen anderen Versionen steckte. Ausl”ser fr den Entschluž nun doch FLCs abzuspielen, war brigens die Erkenntnis, daž man auf einem 68030 in nur 6 Takten aus einem Intel-Wort ein Motorola-Wort machen kann. Wie? - Ganz einfach: ein ror.w #8,D0 erledigt das Gewnschte, zu allem šberfluž kann der '030 auch Worte von ungeraden Adressen lesen, so daž man mit zwei Befehlen ein Intel-Wort aus dem Speicher holen und in das Motorola-Format wandeln kann! 20.10.94 Version 3.5.3 (immer noch) am Player selbst keine Ver„nderungen, allerdings ist die englische Anleitung nochmal leicht berarbeitet worden (Dank an Lars Weinrich). Aužerdem habe ich einen einfachen Benchmark (HYDRAMRK.TOS) beigelegt, der die CPU- und Busperformance mižt, ntzlich um die Busbelastung durch die Videoaufl”sung zu ermitteln. Benutzer von Aufl”sungserweiterungen k”nnen sich zum Beispiel eine Aufl”sung 320x200 in HiColor, 60Hz, SINGLESCAN basteln, allerdings natrlich auf eigene Gefahr (Monitordaten beachten!), mein Rechner erreicht in einer solchen Aufl”sung (bei 20 Mhz) 117% im Ver- gleich zu ST-Hoch auf einem 16MHz-Falken, neuer Rekord bei 40MHz und 688.8 fps ... 06.10.94 Version 3.5.3 Es wird nun berprft, ob die abzuspielende Datei wirklich ein FLI ist, nicht berall wo FLI hintersteht ist auch FLI davor (oder so „hnlich). In Version 4.0 werden wohl FLCs untersttzt werden, allerdings weiter nur in HiColor (ich habe n„mlich einige 320x200 FLCs entdeckt - es gibt sie also doch!). Aužerdem existiert nun die Datei SPEED.TXT in der die er- reichten Maximalgeschwindigkeiten einiger FLIs auf meinem Falcon angegeben sind. 04.10.94 Version 3.5.2 (nicht ver”ffentlicht) Im Fehlerfall wurde die Eingabedatei nicht geschlossen, nun behoben. 02.10.94 Version 3.5.1 (nicht ver”ffentlicht) Tja, nobody's perfect, ein alter, l„ngst tot geglaubter Bekannter war in Version 3.5.0 wieder aufgetaucht (bei FAN.FLI und MOUSE.FLI): , trat allerdings nur beim Spielen von Platte auf, ich habe ihm (hoffentlich!) endgltig Hausverbot erteilt, das mysteri”se work around aus Version 3.1 ist hiermit rehabilitiert ... Der freie Speicher wird nun auf der Statusseite (-i=1) mit angezeigt. Ich berlege fr zuknftige Versionen die Speicherverwaltung aus Version 3.4.x zus„tzlich wieder einzufhren, da bei sehr komplexen Animationen mit sehr grožen Einzelbildern die Abspielgeschwindigkeit beim jetzigen Verfahren stark einbricht (die Festplatte ist halt kein D-Zug... wie w„r's mit 'ner RAM-Disk?!), ein Festplattencache kann den Effekt aber mildern ... 01.10.94 Version 3.5.0 (nicht ver”ffentlicht) Die Speicherverwaltung ist noch einmal komplett umgekrempelt worden, FLIs die nicht komplett in den Speicher passen werden jetzt Bild fr Bild von der Platte gespielt, die Daten fr das n„chste Bild werden wenn m”glich in der Wartezeit fr das n„chste Bild geladen, die Animationen wirken nun viel flssiger, allerdings ist der Betrieb von Diskette dadurch ziemlich unm”glich geworden, aber andererseits sollte jeder Falcon genug Speicher haben, um eine Datei von Diskette komplett laden zu k”nnen (oder gibt es nun doch 1MB- Falcons?) Aužerdem ist der Player mit eingeschalteter VBL-Synchronisation nochmal ein ganzes Stck schneller geworden (bis zu 20%) (eine Zeilenvertauschung bei den Timing-Schleifen macht's m”glich), nun lassen sich auch bei eingeschalteter Vsync-Option meistens 95-105% der Originalgeschwindigkeit errreichen! Ach ja, der Player ist sogar 1kB im Vergleich zur Version 3.4.1 krzer geworden ... Der <-m=xxxxx> Schalter aus Version 3.4.1 existiert brigens weiter, vielleicht kann's irgend jemand gebrauchen und aužerdem kann man so auch ohne bergrože FLIs zu besitzen (so wie ich) der Platte mal ein bižchen Strež machen ... 27.9.94 Version 3.4.1 (nicht ver”ffentlicht) neuer Schalter (-m=xxxxx) eingefhrt, der den Player veranlasst nur xxxxx kB RAM zu benutzen, dazu mužte die Commandine-Auswertung komplett berarbeitet werden, nach Aužen hat sich allerdings nichts ge„ndert. 27.9.94 Version 3.4.0 (nicht ver”fentlicht) Der Player kann nun Dateien, die nicht in den Speicher passen direkt von Diskette oder Festplatte abspielen, wobei das freie RAM als Puffer genutzt wird. Im Gegensatz zu anderen Playern werden Dateien die komplett ins RAM passen auch weiterhin ganz aus dem RAM abgespielt. Im Moment l„dt der Player immer so viel von dem FLI, wie gerade in den Speicher pažt, spielt den Puffer bis kurz vor das Ende ab und l„dt dann nach. Dieses Vorgehen bringt im Schnitt die h”chste Abspielrate, allerdings hakt die Darstellung bei grožem Puffer und sehr langen FLIs ein wenig, da unter Umst„nden mehrere Megabytes nachgeladen werden mssen ... In der n„chsten Version wird es einen Schalter geben, der den Player anweist nur eine gewisse Menge Speicher zu verwenden; aužerdem denke ich ber FLC- Untersttzung nach, weiž jemand ob es auch FLCs in Aufl”sungen kleiner als 640x480 gibt (z.B. 320x200 oder 480*400) ? 26.9.94 Version 3.3.3 (nicht ver”ffentlicht) Dateien, die nicht in den Speicher passen, werden nun auch nicht mehr geladen. Dieser peinliche Fehler steckte in allen bisherigen Versionen und konnte zu einem Totalabsturz fhren... 25.9.94 Version 3.3.2 (nicht ver”ffentlicht) Es gab wohl doch noch einen(?) Fehler im Player (nobody's perfect, vielen Dank an Alexander Clauss!). Manchmal wurde der Chunkheader nicht korrekt gefunden, das (sowieso nicht besonders elegante) work around aus Version 3.1 war halt noch nicht ganz das Gelbe vom Ei, glcklicherweise gibt es eine ziemlich einfache L”sung (manchmal sieht man den Wald vor lauter B„umen nicht - nochmal vielen Dank an Alexander...), jetzt sollten sich alle FLIs abspielen lassen, die auch in den Speicher passen... (mal schauen, wer mich diesmal eines besseren belehrt?!?) 8.9.94 Version 3.3.1 Fr den Grnanteil werden die in HiColor vorhandenen 6 Bit nun auch aus- genutzt, vorher lag das niederwertigste Grnbit brach (d.h. auf Null). 6.9.94 Version 3.3 Schalter zur Anzeige der Header-Information eingebaut, bisher zeigte der Player den Header beim Start kurz an und begann gleich darauf mit dem Abspielen, sehr unsch”n, aber wie gesagt Vergangenheit. Ein paar kosmetische Versch”nerungen, um den Film wird nun ein Zelluloid- streifen dargestellt, ist allerdings nur bei ausreichend hoher Aufl”sung (ab 400x270) voll sichtbar, macht sich aber ganz gut (Eigenlob!). 4.9.94 Version 3.2 (immer noch) Englische Kurzanleitung gestrickt: quick and dirty, aber besser als nix, konstruktive(!) Kritik erlaubt. 13.8.94 Version 3.2 Umstellung auf 68020-Code, das bringt nun je nach Animation bis zu 15% mehr Geschwindigkeit! Um diesen Unterschied messen zu k”nnen wurde ein neuer Schalter (-t=0/1) eingefhrt, der den Player anweist die vorgegebene Abspiel- geschwindigkeit komplett zu ignorieren, neue Spitzengeschwindigkeit bei Aufruf mit -t=0 -v=0 HANDS.FLI : 608 fps (Falcon, 40MHz CPU, 20MHz Bus, 320x200, 66.3Hz). Abfrage auf korrekte Aufl”sung eingebaut, vorher schmiž der Player Bomben, wenn er in einer Aufl”sung mit weniger als 65536 Farben gestartet wurde. 12.8.94 Version 3.1 ist nun (hoffentlich) fehlerfrei, letzte Probleme mit wenigen Animationen beseitigt (FAN.FLI, MOUSE.FLI), irgendwie scheint der Header bei diesen FLIs ein Byte frher zu beginnen (noch in den Daten vom letzten Chunk?), mit dem Effekt, das mein Player nur die zweite H„lfte vom Magic fand und mit einer Fehlermeldung abbrach, das geh”rt nun der Vergangenheit an, sollte das Magic mal nicht stimmen, macht der Player einfach einen zweiten Versuch ein Byte weiter vorne... Ziemlich primitiv, aber es funktioniert, wer eine bessere Idee hat m”ge sich bitte melden... Version 3.0 Endlich sind die Assemblerroutinen fertig, in so einem FLI lauern doch diverse Fallen beim Umstieg von einer Hochsprache (mit FOR- Schleifen) nach Assembler (mit DBRA), die Paketanzahl und die Anzahl der zu setzenden Pixel kann n„mlich Null sein, mit entsprechend fatalen Folgen in den Assembler-Routinen, aus 0.w wird durch Abziehen von 1.w (wegen DBRA) dann 65535.w, und nichts stimmt mehr... Davon hatte die c't nichts erw„hnt (schmoll...) Ferner kann der Player nun endlich auch Animationen loopen und den Vsync ignorieren. Version 2.0 Diese Version ist immer noch in Basic, allerdings wertet sie die Farben korrekt aus und zeigt die Animation nun in HiColor an, durch Umstieg von DRAW auf WPOKE Geschwindigkeitsteigerung um mehrere hundert Prozent, das Compilat spielt Animationen mit 10 fps (frames per second) ab, hat allerdings noch Probleme mit diversen FLIs (FAN.FLI, MOUSE.FLI) Version 1.0 Der erste Player, noch immer in Basic, kann inzwischen schon die ersten Animationen abspielen (BIRDY.FLI), noch ziemlich langsam und ohne Auswertung der Farbinformation, immerhin ist schon was zu sehen... Version 0.0 Erste Basic-Version eines FLI-Analyzers ist fertig, in Anlehnung an einen Artikel in der c't 8/94, das Programm kann den Header auswerten und sich durch die komplette Block-Struktur eines FLIs hangeln. Sven Bruns [EOF]